fix(bitbox): explain an unseeded device instead of looping#722
Closed
TaprootFreak wants to merge 14 commits into
Closed
fix(bitbox): explain an unseeded device instead of looping#722TaprootFreak wants to merge 14 commits into
TaprootFreak wants to merge 14 commits into
Conversation
Promote: staging -> develop
## Automatic Staging PR This PR was automatically created after changes were pushed to staging. **Commits:** 1 new commit(s) ### Checklist - [ ] Review all changes - [ ] Verify CI passes - [ ] Approve and merge to promote into develop --------- Co-authored-by: Josh <joshua.krueger@dfx.swiss> Co-authored-by: TaprootFreak <142087526+TaprootFreak@users.noreply.github.com> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Promote: staging -> develop
## Automatic Staging PR This PR was automatically created after changes were pushed to staging. **Commits:** 1 new commit(s) ### Checklist - [ ] Review all changes - [ ] Verify CI passes - [ ] Approve and merge to promote into develop Co-authored-by: TaprootFreak <142087526+TaprootFreak@users.noreply.github.com> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
## Automatic Staging PR This PR was automatically created after changes were pushed to staging. **Commits:** 1 new commit(s) ### Checklist - [ ] Review all changes - [ ] Verify CI passes - [ ] Approve and merge to promote into develop Co-authored-by: TaprootFreak <142087526+TaprootFreak@users.noreply.github.com>
Promote: staging -> develop
Promote: staging -> develop
## Automatic Staging PR This PR was automatically created after changes were pushed to staging. **Commits:** 1 new commit(s) ### Checklist - [ ] Review all changes - [ ] Verify CI passes - [ ] Approve and merge to promote into develop --------- Co-authored-by: TaprootFreak <142087526+TaprootFreak@users.noreply.github.com> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Promote: staging -> develop
Promote: staging -> develop
## Automatic Staging PR This PR was automatically created after changes were pushed to staging. **Commits:** 1 new commit(s) ### Checklist - [ ] Review all changes - [ ] Verify CI passes - [ ] Approve and merge to promote into develop Co-authored-by: TaprootFreak <142087526+TaprootFreak@users.noreply.github.com>
## Automatic Staging PR This PR was automatically created after changes were pushed to staging. **Commits:** 1 new commit(s) ### Checklist - [ ] Review all changes - [ ] Verify CI passes - [ ] Approve and merge to promote into develop Co-authored-by: TaprootFreak <142087526+TaprootFreak@users.noreply.github.com>
## Automatic Staging PR This PR was automatically created after changes were pushed to staging. **Commits:** 1 new commit(s) ### Checklist - [ ] Review all changes - [ ] Verify CI passes - [ ] Approve and merge to promote into develop --------- Co-authored-by: TaprootFreak <142087526+TaprootFreak@users.noreply.github.com>
A BitBox paired without a wallet set up (no seed) cannot derive an ETH address. The empty address read failed as a generic error and bounced the user into the silent re-scan loop with no explanation, so a brand-new device was effectively unusable with no hint why. After pairing, read the device's firmware status via the new bitbox_flutter getDeviceStatus and, when it reports `uninitialized`, emit a dedicated BitboxNotInitialized state that tells the user to set up or restore a wallet on the device first. The state offers a retry that re-checks the status without re-pairing and, crucially, does not arm the re-scan timer, so the device is no longer picked up and re-paired in a loop. Only `uninitialized` is treated as "no wallet"; other non-ready statuses keep the existing path. Temporarily pins bitbox_flutter to the fix branch; moves to the v0.0.9 tag once the plugin PR is merged and tagged.
Contributor
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Connecting a brand-new BitBox that has no wallet set up (no seed) left the user stuck. Pairing succeeds, but the device has no seed to derive an ETH address from, so
getETHAddresscomes back empty. That empty read failed as a generic error →BitboxNotConnected→ a SnackBar "something went wrong" → and because the re-scan timer is re-armed, the device is immediately found again and the user is walked through the pairing code → fail → SnackBar loop, with no hint that the real problem is simply an un-set-up device.(The earlier fix #710 stopped the empty address from being persisted — no more grey screen — but did not distinguish "no seed" from a transient empty read.)
What changed
After channel-hash verify, read the device's firmware status via the new
bitbox_fluttergetDeviceStatus()(cached read, no device round-trip). When it reportsuninitialized, emit a dedicatedBitboxNotInitializedstate that explains the user must set up / restore a wallet on the device first.recheckDeviceStatus) that re-reads the status — if the user has since set up a wallet, the connection continues without re-pairing.uninitializedis treated as "no wallet". Other non-ready statuses (e.g. firmware-upgrade-required) intentionally keep the existing failure path rather than being mislabelled.The address-derivation/observe/sign tail of
confirmPairingwas extracted into_acquireWalletAndConnect()so the initial flow and the retry share one path.Dependency
Requires
bitbox_fluttergetDeviceStatus()from DFXswiss/bitbox_flutter#29. This PR temporarily pins the plugin to that fix branch; it will be moved to thev0.0.9tag once #29 is merged and tagged. Kept as Draft until then.Test plan
flutter analyze— clean (only the pre-existing generated-i18n.dartwarning)flutter test— bitbox cubit / service / view suites all greenBitboxNotInitialized, no wallet created, no re-scan loop (state stays stable); retry continues once seeded; retry stays while still unseeded; no-op off-stategetDeviceStatuspass-through via the simulatorBitboxNotInitializedrenders retry + cancel; retry callsrecheckDeviceStatusde/enARBs, regenerated